Electronic data entry forms typically include a number of data fields into which a user may enter data with a keyboard or other input device. Since the data entered into an electronic data entry form are often changed, it is common to open a form for editing with relation to a specific data record included therein. Previously entered data usually appear in data fields that a user may edit. After revisions or additions have been made to a form, it will typically not be apparent which of the data fields were revised or added.
Previous attempts to track changes in data fields have focused on maintaining an invisible temporary indicator of the status of data fields, which is used for informing a supporting database of revisions that have been made to data in the data fields. For example, Kovan et al. (U.S. Patent Application Publication No. U.S. 2002/0166118) uses two objects to store data entered into a hypertext markup language (HTML) form. A first object stores initial data values previously entered into data fields of the HTML form. A second object is copied from the first object, and a user revises data stored in the second object. The second object thereby provides a temporary current status of the data fields based on the initial content obtained from data in the original database, which are reflected in the first object. However, there is no indication to the user of the data fields that have been revised. To identify the data fields that have been changed, the user must first submit the revised HTML form to a server. A comparison is then performed between the second and first objects to determine the data fields that have current data values different from their initial data values. These differing data values are sometimes referred to as “dirty” data. The underlying database is informed of which data are dirty (i.e., which data fields were changed), but the user must rely on his or her own memory of what is observed when the results are displayed.
As another example, Moore et al. (U.S. Pat. No. 5,317,730) filters a source list of data from a permanent database through an insert list, a delete list, and a flagged list to display an “apparent” list showing the current status of changes to the source list of data. However, the user only sees the apparent list showing the current status of the data. As the user inserts data, deletes data, or flags data, the filters cause the apparent list to be updated and displayed to the user. Thus, again, there is no persistent indication to the user whether data has been inserted, deleted, or otherwise revised in the data fields.
Some application programs provide a detailed indication of a change to specific data entry. For example, in tracking revisions to a text document, a word processor can indicate an insertion of text into the document by displaying the inserted text in a different color than the text originally provided in the document. This approach is useful when more than one author edits the document, since the text inserted or changed by each author is typically shown in a different color. However, this kind of detailed indication is not useful for enabling a single user to visually determine whether he or she had already revised a data field in a data entry form. Also, the user often does not need to see the specific changes to data that were made. Instead, the user may only wish to know which data fields were previously changed, and which ones still need to be changed. While a word processor may indicate that a change was made somewhere in a line of text by simply displaying a vertical bar at a right margin next to the revised line(s) of text, this indication is not sufficiently detailed for a user to quickly identify which data was changed. A bar provides a system for indicating change to a free-form or free-flowing document, not change to discrete data fields. A bar therefore solves a different problem, wherein the bar is more of a callout to reviewers than an indicator to an author while editing. Furthermore, changes to multiple data fields may be included in a single line, and based upon a bar appearing in the margin of any line in which a change has been made, a user would not be able to determine the data fields in the line that were modified.
Although simple in concept, there is an unmet need to provide a persistent indication to a user of whether a data field has been modified. This indication would be useful in reminding the user of the position where changes in a form were made. A data field indication would also notify the user if a data field changed as a result of an unintended accidental revision. Inadvertent changes would then be easy to notice visually. Likewise, data that was intended to change, but wasn't changed, is easy to notice. For example, cut and paste operations can fail due to hitting the incorrect key combination for pasting, or attempting to pass too many characters into a field. Another example is that a user may accidentally delete data from a field while intending to copy it. Thus, an indication is needed to help the user to visually perceive data fields that were changed in an electronic data entry form or other document with data fields.